inscatolati - Get out of the box! :)

Just run:

# apt-get install linuxlogo

and follow the instructions. Tipically, you will have to modify the file /etc/inittab and add something like:

2:23:respawn:/sbin/getty -f /etc/issue.linuxlogo 38400 tty2

The whole message looks something like:

Setting up LVM Volume Groups... Reading all physical volumes. This may take a while...

followed by lot of kernel messages.

Well, that's the problem: lvscan, to find all the phyisical volumes, will just scan the first few sectors of every device on the system.

If you happen to have something particularly slow, lot of devices, or ... you are an aficionado of devfs (which will probe modules as pvscan tries to find those volumes), you will want to change /etc/lvm.conf.

Just add something like:

filter = [ "a|/dev/md*|", "a|/dev/sd*|" ]

in that file, to tell pvscan to search only in /dev/md* and /dev/sd*

Ok, let's say you have created your ext3 root filesystem, and you want to use it with data=journal, instead of the default data=ordered. You cannot umount it, so you try:

mount -o remount,data=journal

Most likely, the command will fail with:

mount: / not mounted already, or bad option

If you also run dmesg, you will see the error:

EXT3-fs: cannot change data mode on remount

so you're stuck. Also, the root partitions gets mounted before fstab is read, so... it's a bit harder to get the options right.

If you cannot reboot the system, the only thing you can try is to play with pivot_root or similar, to try to temporarily move the root on tmpfs / ramdisk / ... but would still need lot of restarting, mount --bind and so on to move the services to the new root.

If you can afford to reboot, and you want data=journal after every reboot, you can use:

tune2fs -o journal_data /dev/sda1

where sda1 is your root partition. Alternatively, on LILO or grub command line, you can pass the option:

rootflags=data=journal

initrds created with mkinitramfs, mkinitrd, yaird or any other tool can sometime contain errors that make your system un-bootable, or that output error during the boot process. It is usually a pain to debug those errors, as... you often don't have a shell, needed softwares are missing from the initrd, ...

Generally, there are two approaches that can be easily used to debug an initrd:

• uncompress the initrd, and have a peek in the scripts to see what's being done and what it is doing when the init process stops (and why) - always works.

• at boot time, have the initrd output some debugging lines, or get a prompt to try to manually understand what's going wrong or why the commands are failing. Using this method requires support from the tool used to create the initrd, so it won't be discussed in this note.

So, to access the content of an initrd, you need to run a few commands depending on the format of the initrd itself. Nowdays, most initrds are either gzip-compressed cpio files, cramfs or other more or less esotheric file systems. You can start with something like:

% file -Ls /boot/initrd.img

If you are lucky, it will be a cramfs:

/boot/initrd.img-2.6.8-3-686-smp: Linux Compressed ROM File System data, [...]

just mount it with something like:

% mount -o loop /boot/initrd.img /mnt/whatever

If you are a bit less lucky, it will be gzip compressed:

/boot/initrd.img: gzip compressed data, from Unix,

Start by just uncompressing it:

% gzip -cd < /boot/initrd.img > /tmp/initrd.uncompressed

Repeat the "file" command above against /tmp/initrd.uncompressed. If you are lucky, again, it will be a filesystem. Just mount it with the same "mount -o loop..." as above. If you are a bit less lucky, you will see something like:

$ file -sL /tmp/initrd.uncompressed /tmp/initrd.uncompressed: ASCII cpio archive (SVR4 with no CRC)

which means that the initrd is a simple cpio archive. Uncompress it with something like:

$ cpio --extract --make-directories < /tmp/initrd.uncompressed

Now, you can start your debugging by either looking into /linuxrc, /init, or /sbin/init. You can obviously modify the filesystem, and reverse the steps to create a new initrd to test. Good luck!

mkinitramfs allows you to specify some parameters on the LILO or GRUB prompt to easily (sure) debug problems. Most useful parameters are probably:

• debug, to have all the shell scripts on the initrd run with the -x parameter, and the output logged in /tmp/initramfs.debug on the ramdisk. To have the output sent to stdout, specify something like debug=/dev/console.

• break, to have the initrd return a shell prompt. If no parameters are specified, the prompt will be returned when most convenient to the initrd (at current time, just before mounting the root filesystem - premount). Otherwise, you can specify something like break=whatever, to ask the initrd to stop at exactly the specified step. Steps currently defined by mkinitramfs are: top, modules, premount, mount, bottom and init.

• blacklist, if you suspect a module is causing problems to your hardware. Specify something like blacklist="module1 module2" to have module1 and module2 not loaded at boot time.

As I use grub on my system, to specify those parameter at boot time, I usually press 'e' on the line I usually boot from. Once there, I modify the line:

kernel /vmlinuz root=/dev/mapper/root ro

to have the options I need:

kernel /vmlinuz root=/dev/mapper/root ro break=top

and finally press 'b' to get the system booted with the specified parameters.